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Abstract 


The  unpredictable  nature  of  the  21st  century  national  security  environment  in 
conjunction  with  severe  downward  budgetary  pressures  has  placed  a  new  emphasis 
on  achieving  mission  success  with  fewer  resources.  As  the  Department  of  Defense 
has  sought  to  transform  itself  to  meet  this  new  requirement,  Open  Architecture  (OA) 
has  been  viewed  as  one  innovative  tool  for  reducing  costs  (through  greater 
efficiencies,  enhanced  competition,  lower  life-cycle  cost,  etc.)  while  maintaining  the 
ability  to  quickly  respond  to  the  ever-changing  threat  environment.  Consistent  with 
this  approach,  product  lines,  based  on  OA  foundational  principles,  have  recently 
emerged  as  a  means  to  streamline  systems,  achieve  greater  levels  of  reuse,  and 
reduce  costs.  As  directed  by  the  Assistant  Secretary  of  the  Navy  (Research, 
Development  and  Acquisition,  ASN[RDA]),  the  Naval  Enterprise  is  preparing  to 
implement  Open  Architecture  Pilot  Projects  to  validate  a  range  of  implementation 
approaches  and  evaluate  their  technical  and  business  advantages  as  a  means  to 
attack  budget  and  output  deficiencies.  This  research  topic  will  provide 
recommendations  on  how  best  to  start  implementing  the  product  line  approach  in 
programs  across  the  Naval  Enterprise,  consistent  with  current  OA  policy. 

Introduction 

The  Naval  Enterprise  Acquisition  Corps  is  being  pressured  to  improve  performance. 
National  Security  Systems — the  weapon  systems  used  to  fight  our  wars — have  realized  cost 
growths  outpacing  rates  of  inflation.  System  deliveries  are  persistently  late,  driving  costs 
even  higher.  In  2009,  the  Government  Accountability  Office  reported  that  “the  cumulative 
cost  growth  in  the  Department  of  Defense’s  portfolio  (including  the  Naval  Enterprise)  of  96 
Major  Defense  Acquisition  Programs  (MDAPs)  was  $296  billion  from  first  estimates,  and  the 
average  delay  in  delivering  promised  capabilities  to  the  warfighter  was  22  months”  (GAO, 
2009).  Today’s  economic  conditions  place  increased  pressure  on  acquisition  budgets. 
Likewise,  political  and  civil  unrest  around  the  world  has  put  a  growing  strain  on  the  Navy’s 
resources — including  ships,  aircraft,  personnel  and  financial.  Because  of  these  influences, 
the  Department’s  acquisition  force  has  been  asked  to  find  ways  to  enhance  mission 
performance,  significantly  lower  costs,  and  increase  quantity  while  maintaining  the  same  or 
less  budget. 

Drawing  upon  experience  in  driving  transformation  through  Open  Architecture,  the 
Navy  is  looking  to  take  the  next  step  towards  improving  how  it  acquires  and  supports  its 
National  Security  Systems  through  Open  Architecture  Product  Lines. 
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Background 


Figure  1 


A  strong  culture  of  achievement  runs  deep  in  the  U.S.  Naval  Enterprise.  It  is  a  proud 
organization  that  plans  carefully  and  executes  smartly  to  continue  its  long  winning  tradition. 
Inherently,  “we”  collectively  resist  change  as  a  conservative  and  understandable  approach 
towards  avoiding  risk.  What  is  our  path  when  we  are  “shewn”  an  environment  of  avoidable 
hardship? 


Prudence,  indeed,  will  dictate  that  Governments  long  established  should  not  be 
changed  for  light  and  transient  causes;  and  accordingly  all  experience  hath 
shewn  that  mankind  are  more  disposed  to  suffer,  while  evils  are  sufferable  than 
to  right  themselves  by  abolishing  the  forms  to  which  they  are  accustomed.  But 
when  a  long  train  of  abuses  and  usurpations,  pursuing  invariably  the  same 
Object  evinces  a  design  to  reduce  them  under  absolute  Despotism,  it  is  their 
right,  it  is  their  duty,  to  throw  off  such  Government,  and  to  provide  new  Guards 
for  their  future  security.  (Declaration  of  Independence) 


We  are  not  proposing  to  throw  off  the  Government,  but  to  throw  off  the  behaviors  that  have 
led  us  to  high  costs  and  low  output,  collectively  known  as  “poor  performance  in  Acquisition.” 

The  evolving  and  unpredictable  threat  environment  coupled  with  enormous 
pressures  on  our  nation’s  defense  budget  has  caused  the  Naval  Enterprise  to  consider 
dramatic  changes  in  its  approach  to  systems  acquisition  and  sustainment.  Our  enemies  are 
adaptive,  continuously  study  our  behavior,  and  counter  with  new  behaviors  of  their  own. 
They  use  Improvised  Explosive  Devices  (lEDs)  and  suicide  bombers  to  attack  us  at  times 
and  places  of  their  choosing.  Terrorists  launch  crude  homemade  rockets  from  within  urban 
neighborhoods  to  invite  collateral  damage  and  attempt  to  wither  our  resolve.  Constant 
change  is  attacking  us,  and  these  new  threats,  techniques,  and  situations  demand  that  we 
change  our  planning  models  and  build  new  systems  to  not  only  protect  our  soldiers,  but  to 
provide  an  adaptive  advantage  and  protection  from  evolving  threats.  The  Naval  Enterprise 
must  provide  the  warfighter  with  more  than  new  systems.  We  must  deliver  evolving 
warfighting  systems  that  are  finely  tuned,  yet  adaptable  in  days,  not  years.  They  must  be 
designed  for  quick  change,  and  to  grow  and  change  with  little  cost.  We  must  leverage  what 
we  already  have,  and  distribute  solutions  quickly  to  different  systems  and  platforms. 

The  Naval  Enterprise  has  been  directed  by  ASN/RDA  to  execute  a  series  of  product 
line  pilot  projects  in  concert  with  current  Naval  Open  Architecture  efforts  as  a  means  to 
attack  budget  and  output  deficiencies.  The  following  pages  provide  an  overview  of  our 
approach. 
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Open  Architecture 

Open  Architecture1  (OA)  can  reduce  costs  and  cycle  time  and  speed  insertion  of  new 
capabilities.  OA  is  a  development  and  program  management  technique  providing  a 
framework  for  creating  systems  that  are  less  expensive  to  build  and  maintain,  and  deliver 
new  features  more  quickly  to  the  warfighter.  The  benefits  of  OA  include  reduced  costs, 
shorter  development  schedules,  and  modularity.  As  defined  by  Guertin  and  Clements 
(2010),  the  following  are  core  principles  of  the  Open  Architecture  approach: 


1 .  Modular  designs  with  loose  coupling  and  high  cohesion  that  allow  for 
independent  acquisition  of  system  components; 

2.  Continuous  design  disclosure,  appropriate  use  of  data  rights  allowing  greater 
visibility  into  an  unfolding  design,  and  flexibility  in  acquisition  alternatives; 

3.  Enterprise  investment  strategies  that  maximize  reuse  of  system  designs  and 
reduce  total  ownership  costs  (TOC); 

4.  Enhanced  transparency  of  system  design  through  open  peer  reviews; 

5.  Competition  and  collaboration  through  development  of  alternative  solutions 
and  sources; 

6.  Analysis  to  determine  which  components  will  provide  the  best  return  on 
investment  (ROI)  to  open,  i.e.,  which  components  will  change  most  often  due 
to  technology  upgrades  or  parts  obsolescence  and  have  the  highest 
associated  cost  over  the  lifecycle. 


A  design  following  these  six  principles  as  outlined  by  Guertin  and  Clements  (2010) 
should  result  in  an  affirmative  answer  to  the  fundamental  OA  question:  Can  a  qualified  third 
party  add,  modify,  replace,  remove,  or  provide  support  for  a  component  of  a  system,  based 
only  on  openly  published  and  available  technical  and  functional  specifications  of  the 
component  of  that  system? 

Product  Lines 

Creating  and  using  product  lines  is  a  method  to  streamline  the  development  of 
systems,  generate  opportunities  for  reuse,  and  reduce  costs  in  development,  testing,  and 
logistics.  A  “Product  Line,”  as  we  use  the  term,  is  a  coordinated  component  design,  sharing 
common,  managed  core  building  blocks  which  have  attributes  and  features  that  satisfy  the 
specific  needs  of  a  particular  market  segment  or  mission  (Software  Engineering  Institute 
[SEI],  n.d.).  Product  Line  development  results  in  a  set  of  core  modules  and  assets  that  form 
the  cornerstones  for  building  future  National  Security  Systems.  Assets  include  designs, 
patterns,  drawings,  source  code,  specifications  and  other  cumulative  products  that  are 
produced  as  part  of  an  engineering  effort  to  create  a  materiel  solution.  Product  Lines  can  be 
viewed  as  a  logical  extension  of  several  OA  principles — in  essence  “Open  Architecture  in 
action.” 

As  related  to  information  technology,  Product  Lines  exist  for  hardware,  software,  and 
a  combination  of  both.  Product  Lines  also  apply  to  non-information  technology  specific 
solutions — such  as  automotive  and  mechanical  systems.  When  properly  implemented, 
Product  Lines  can  decrease  system  lifecycle  costs,  lower  risk,  and  shorten  development 
time.  Because  the  Product  Line  approach  is  centered  upon  reuse  of  existing  assets, 


1  Definitions  available  at  the  Defense  Acquisition  University  website  (n.d.). 
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significant  testing  and  validation  is  reduced,  saving  time  and  resources  with  follow-on 
benefits  like  improvements  in  component  reliability. 


Figure  2 


Product  Line  Benefits 
Lower  Lifecycle  Costs 

More  reuse  produces  more  savings.  Product  Lines  reuse  core  assets  to  create  new 
products  and  systems,  avoiding  standalone  development  costs.  Programs  that  use  Product 
Line  products  realize  cost  avoidance  savings.  As  designs,  components,  and  products  are 
reused  across  multiple  programs,  higher  quantity  orders  improve  production  efficiencies, 
driving  unit  costs  down.  When  a  program  adopts  a  Software  Product  Line,  labor 
requirements  as  compared  to  new  development  are  mostly  limited  to  integration —  lowering 
costs.  Fielded  Product  Lines  experience  lower  maintenance  costs  because  of  “seasoned” 
reliability,  due  to  the  maturity  of  the  design  and  code.  Examples  of  lower  lifecycle  costs  from 
the  Army’s  Common  Avionics  Architecture  System  (CAAS)  Product  Line  include  a  66.67% 
reduction  in  new  system  development  costs,  50%  reduction  in  integration  costs,  50% 
reduction  in  software  maintenance  costs,  and  95%  reduction  in  training  costs  (Clements  & 
Bergey,  2005). 

Shorter  Development  Schedules 

Developing  hardware  or  software  from  scratch  takes  more  time  than  beginning  with  a 
design  that  is  near  complete  for  the  problem  at  hand.  As  noted  by  the  Defense  Science 
Board,  a  typical  major  system  acquisition  takes  roughly  10-15  years.  Development  of 
comparable  systems  in  the  commercial  sector  is  usually  completed  in  anywhere  from  one 
third  to  one  half  the  time.  Acquisition  of  most  information  technology  (e.g.,  national  security 
systems  and  business  systems)  within  the  DoD  exceeds  typical  commercial  development 
timelines  by  anywhere  between  three  to  four  times  (DoD,  2009). 
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Product  Quality 

Designs  that  have  already  been  through  development,  test,  certification,  and  fielding 
are  likely  to  perform  better  than  those  that  have  not.  Beginning  a  project  with  a  series  of 
Product  Lines  which  are  already  proven  is  a  large  advantage  for  the  Naval  Enterprise.  The 
amount  of  development  work  needed  is  smaller,  and  smaller  projects  have  higher  rates  of 
success.  The  cost  for  much  of  the  testing  can  likely  be  “approved  by  extension”  when  the 
testing  organization  agrees  that  much  of  the  implemented  design  has  not  changed. 

Open  Architecture  and  Product  Lines  Together 

Open  Architecture  systems  are  decomposed  into  “subsystem”  components,  which 
become  natural  functionally  partitioned  units  and  a  logical  location  to  formulate  a  Product 
Line.  In  a  similar  fashion,  Product  Lines  use  core  assets  that  are  assembled  and  integrated 
in  specific  ways  to  create  a  family  of  products.  When  systems  adopt  the  OA  technical 
principles  as  articulated  by  Open  Architecture  Enterprise  Team,  they  are  in  a  position  to  take 
full  advantage  of  Product  Lines.  The  difficult  parts  of  Product  Lines,  and  for  that  matter, 
Open  Architecture,  are  the  business  and  marketplace  rules  that  surround  the  Program. 
These  rules  are  typically  conceived  or  structured  by  the  government.  The  following  list  of 
business  constructs  is  typical  of  needed  behavior  for  structuring  and  executing  effective 
Product  Lines.  When  implemented  together,  these  constructs  result  in  the  creation  of  a 
“Product  Line  Factory.” 


1 .  Data  rights  for  technical  data  and  computer  software.  A  minimum  of 
Government  Purpose  Rights  (GPR;  DoD  OA  Working  Group,  2011)  is 
needed  for  Product  Line  success.  Without  requisite  data  rights  for  assets, 
there  are  limits  on  reuse  and  who  the  technical  data  and  software  source 
code  can  be  shared  with. 

2.  Shared  risks  with  other  programs.  Product  Lines  are  hinged  upon 
providing  products  for  use  across  multiple  programs.  Sharing  risk  among 
programs  reduces  costs  to  individual  programs,  and  ultimately  creates  value- 
add  for  programs  using  the  Product  Line. 

3.  Shared,  common  requirements  across  programs.  Product  Line  products 
must  provide  functionality  that  meets  customer  requirements.  Within  the 
DoD,  requirements  are  typically  written  from  a  platform  or  system 
perspective.  A  Product  Line  approach  requires  merging  requirements  around 
capabilities  to  support  establishing  the  assets  needed  to  support  the  full 
scope  of  products  within  the  Product  Line.  Managing  “variation  points”  within 
a  Product  Line  can  mean  the  success  or  failure  of  software  sharing 
opportunity,  and  the  associated  potential  for  saving  time,  money,  and  for 
delivering  already  tested,  proven  system  components  to  the  warfighter. 

4.  Funding  constructs  that  allow  Product  Line  organizations  to  use  funds 
from  or  across  multiple  programs.  Within  a  Product  Line  factory,  shared 
core  assets  are  used  to  create  products  in  a  prescribed  way  for  use  by  many 
customers.  The  customers  may  use  the  products  on  different  systems  or 
platforms.  The  core  asset  base  must  be  maintained  to  support  the  full  family 
of  products;  it  is  not  segregated  into  elements  that  support  only  one  product. 
As  soon  as  the  Product  Line  has  customers  across  program  lines,  funds  will 
be  mixed  in  supporting  the  asset  base.  Mechanisms  for  supporting  mixed 
funding  will  be  developed  as  necessary. 
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5.  Lines  of  authority  that  properly  account  for  Product  Line  managers 
supporting  many  customers  across  programs,  domains,  and  eventually, 
Services.  The  scope  of  products  in  a  Product  Line  can  attract  customers 
across  program,  domain,  and  Service  boundaries.  The  Product  Line  model 
treats  all  users  as  customers  with  the  same  rights,  responsibilities,  and 
authority,  regardless  of  organization.  The  DoD  is  not  typically  this 
organizationally  agnostic.  A  Product  Line  manager  will  need  a  new  model  to 
function  efficiently.  While  many  industry  approaches  to  producer/customer 
relationships  do  not  fare  well  inside  the  government,  it  will  be  essential  to  find 
a  workable  structure  to  allow  the  Product  Line  and  its  customers  to  work 
effectively  and  productively  as  producer/consumer. 

Naval  Enterprise  Product  Line  Pilot  Projects 

The  Naval  Enterprise  is  developing  a  series  of  frameworks  for  implementation  and 
operation  of  a  Product  Line  factory  to  provide  an  initial  set  of  process,  organization, 
procedure,  and  governance  templates  with  development  guides  to  support  Product  Line 
execution.  These  frameworks  will  be  tested  through  a  series  of  Product  Line  pilot  projects. 
The  pilot  projects  will  begin  with  an  existing  product,  while  a  framework  is  designed  to 
support  it.  The  strategy  for  conducting  these  pilots  will  begin  with  a  “seed”  product,  followed 
by  the  construction  of  processes,  an  organization,  and  core  asset  base  from  that  seed. 

Once  these  steps  have  been  completed,  a  second  candidate  product  for  the  Product  Line 
will  be  selected  to  demonstrate  the  factory’s  ability  to  function  successfully  on  a  repeatable 
basis. 


The  Product  Line  project  framework  is  a  set  of  templates,  draft  procedures,  example 
documents,  and  guides  designed  to  be  used  as  the  starting  points  for  the  Product  line  pilot 
projects.  The  framework  elements  form  a  skeleton  upon  which  the  product  line  manager 
can  build  the  essential  business  and  technical  structures  necessary  to  get  the  project 
started.  As  projects  use  the  framework  and  move  through  startup  to  operation,  problems  will 
be  encountered  requiring  corrections,  additions,  and  expansions.  Carnegie  Mellon 
University,  Software  Engineering  Institute  (CMU  SEI)  has  published  “A  Framework  for 
Product  Line  Practice,  Version  5.0”  (Northrop  &  Clements,  et  al.,  2007)  that  provides 
extensive  information  on  the  technical  and  business  practices  integral  to  a  software  product 
line.  The  document  also  describes  how  these  differ  from  standalone  product  practices.  The 
Naval  Enterprise  framework  differs  from  SEI’s  targeted  commercial  audience  in  that  it  is 
focused  on  startup  structures  inside  the  DoD  (Northrop  &  Clements,  et  al.,  2007).  SEI  is 
only  one  of  several  different  product  line  frameworks;  others  have  been  developed,  including 
an  approach  laid  out  by  Kang,  Sugumaran,  and  Park  (2009). 

Example  templates  and  associated  development  guides  include  a  new  OA  business 
case  guide,  the  Navy  OA  Contract  Guidebook  for  Project  Managers,  the  CMU  SEI 
Structured  Intuitive  Model  for  Product  Line  Economics  (SIMPLE;  Northrop  &  Clements,  et 
al.,  2007)  economic  model,  and  a  guide  on  use  within  the  Navy  Enterprise,  and  a  template 
for  use  in  deciding  which  programs  to  select  as  Open  Architecture  Product  line  pilots. 

The  Product  Line  approach  may  require  significant  adjustments  in  the  way  the  Navy 
typically  does  business.  The  Product  Line  factory  will  generate  products  that  are  used 
across  programs  and  their  associated  funding  lines.  The  products  will  fulfill  requirements 
across  different  warfare  areas  and  platforms.  The  Product  Line  factory  manager  will  have 
responsibility  to  support  and  respond  to  multiple  programs  which  may  cross  domain  and 
Service  lines.  The  pilot  projects  offer  the  opportunity  to  investigate  these  issues  and  craft 
effective  solutions  while  creating  functional  organizations  and  delivering  real  products. 
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Framework  templates  are  broken  down  into  four  phases  to  match  a  four  phased 
approach  to  pilot  project  completion:  deciding  what  to  build  (Phase  I);  developing  the  initial 
asset  base  (Phase  II);  developing  the  Product  Line  production  and  support  machinery 
(Phase  III);  and  operating  the  factory  to  create  and  support  products,  and  implementing 
product  variations  (Phase  IV).  The  templates  are  intended  to  address  every  task  within 
each  phase  with  special  emphasis  on  tasks  that  are  unique  to  Product  Lines  or  that  present 
special  challenges  in  a  Naval  Enterprise  environment.  Addressing  a  Product  Line  scope, 
cross  product  funding,  cross  domain  product  support,  and  development  and  configuration 
management  of  a  Product  Line  asset  base  and  associated  products  represents  the  kind  of 
tasks  that  are  different  from  a  non-product  line  acquisition  approach. 

The  framework  templates  and  supporting  material  will  be  revised  during  the  pilots  to 
reflect  lessons  learned  and  represent  a  key  product  of  the  pilot  projects.  Follow-on  Product 
Line  efforts  will  have  a  well-defined  starting  point  for  processes,  governance,  and 
organizational  constructs  that  have  been  tested  for  effectiveness. 

Steps  to  Product  Lines 

Our  initial  approach  to  Product  Lines  draws  heavily  on  information  from  the  CMU  SEI 
(Northrop,  2004);  the  following  outline  provides  a  roadmap  of  activities  that  can  be  used  to 
start  up  a  new  product  line  entity,  as  shown  in  Figure  3.  These  steps  can  be  implemented  in 
different  order  based  on  the  relative  organizational  readiness  for  Product  Line 
implementation.  Several  parallel  activities  can  be  worked  simultaneously.  Because  this 
outline  is  a  whole-lifecycle  model,  one  should  assume  these  activities  occur  over  years 
rather  than  months. 
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Figure  3.  The  Adoption  Factory  Pattern 

(Northrop,  2004) 

Phase  I:  What  to  Build 

The  decision  to  implement  a  Product  Line  starts  with  deciding  where  a  program  is 
with  respect  to  the  lifecycle  of  products  being  considered  and  assessing  where  those 
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products  are  going.  Initiating  a  Product  Line  can  take  either  of  two  approaches,  proactive  or 
reactive  (Northrop,  2004).  If  starting  with  a  clean  sheet,  the  proactive  approach  is  used  to 
create  the  organization,  the  core  asset  base,  the  procedures  and  tools,  and  all  the 
governance  elements  for  the  Product  Line.  If  starting  with  an  existing  product,  then  the 
reactive  approach  can  be  used.  In  this  approach,  core  asset  components  are  dissected 
from  the  existing  product  while  organization,  processes  and  procedures,  tools,  and 
governance  are  either  created  from  scratch  or  crafted  by  reorganizing  and  restructuring 
existing  materials.  In  both  cases,  the  first  task  is  to  define  the  Product  Line  scope  and 
determine  that  it  is  a  suitable  approach  from  a  business  and  technical  perspective. 


1 .  Define  and  validate  product  line  scope.  The  first  step  in  defining  a  Product 
Line  is  to  develop  a  general  scope  statement.  The  scope  is  the  definition  of 
what  attributes,  behaviors,  and  aspects  are  within  scope  and  those  that  are 
outside.  This  initial  scope  statement  informs  the  business  case  and  other 
analysis  that  follows,  and  in  turn,  is  refined  as  those  products  are  developed. 
The  scope  documentation  will  not  be  complete  until  the  Product  Line  is 
complete.  During  implementation,  the  scope  document  continues  to  capture 
the  commonalities  that  members  of  a  Product  Line  share  and  the  ways  in 
which  they  differ. 

a.  Develop  a  business  case.  Once  you  have  decided  to  investigate  the 
Product  Line  approach  for  a  specific  product  area,  a  Business  Case  is 
needed  to  determine  the  efficacy  of  the  approach  (Northrop  & 
Clements,  et  al.,  2007,  Building  a  Business  Case  section).  The 
Business  Case  informs  your  deliberations  by  looking  at  projected 
costs,  return  on  investment,  risks,  potential  marketplace,  and 
comparing  and  contrasting  the  advantages  and  disadvantages  of  a 
Product  Line  versus  standalone  product  development  approaches. 

The  business  case  works  hand  in  hand  with  the  economic  model  to 
provide  a  qualitative  and  quantitative  assessment  of  the  costs  and 
benefits  of  switching  to  a  Product  Line  approach. 

b.  Develop  a  market  description.  The  market  description  tries  to 
define  the  number  of  products  that  can  be  provided  to  customers 
across  the  proposed  Product  Line  in  breadth  and  depth  (Northrop  & 
Clements,  et  al.,  2007,  Market  Analysis  section).  Looking  across  the 
Naval  Enterprise,  there  are  three  classes  of  potential  customers: 
those  who  are  able  and  willing  to  use  the  products;  those  who  are 
able  but  hesitant;  and  those  who  are  unable  (barred  by  contract  or 
law).  If  there  are  insufficient  potential  customers  in  the  able 
categories  to  generate  significant  cost  savings  through  reuse,  then  the 
business  case  and  economic  model  need  to  assess  other 
advantages.  Implementing  a  Product  Line  may  still  be  justified  by 
improvements  in  quality  and  rapid  responsiveness  to  changing 
requirements. 
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Figure  4 

c.  Conduct  a  technology  assessment.  The  technology  assessment  is 
focused  on  both  ensuring  that  the  technology  necessary  for 
implementing  a  Product  Line  for  the  products  envisioned  are 
available,  and  that  the  best  set  of  technologies  for  implementing  and 
operating  the  Product  Line  is  selected  (Northrop  &  Clements,  et  al., 
2007,  Technology  Forecasting  section).  Within  the  confines  of  serial 
processing,  Moore’s  Law  can  be  used  as  a  reasonable  basis  to 
describe  the  rate  of  change  in  available  processing  power  which,  in 
turn,  enables  advances  in  software  technology  that  supports  software 
automation,  variation  modeling,  and  new  heuristics.  In  the  future,  it  is 
probable  that  the  pace  of  technological  innovation  from  parallel 
processing  and  other  advances  will  significantly  alter  the  assumptions 
traditionally  held  under  Moore’s  law.  As  a  consequence,  technology 
assessments  may  need  to  be  updated  to  reflect  such  transformational 
changes  in  technology  development  (Dally,  2010).  Process 
innovations  and  new  strategies  and  techniques  offer  improvements  in 
production  and  deployment  of  new  products,  configuration 
management,  and  customer  support  capabilities.  Standards  bodies 
continually  process  changes  and  additions  to  their  products  which 
often  offer  opportunities  to  increase  commonality  and  reuse.  All  of 
these  technology  elements  need  to  be  factored  into  the  selection  of 
the  initial  product  and  the  design  of  the  Product  Line.  Once  the 
Product  Line  factory  is  established,  the  technology  assessment  will 
become  the  starting  point  for  the  technology  roadmap. 

d.  Develop  an  economic  model.  An  economic  model  helps  structure 
the  assessment  of  the  costs  and  benefits  of  adopting  a  Product  Line 
approach  in  comparison  with  a  standalone  product  approach.  The 
Structured  Intuitive  Model  for  Product  Line  Economics  (SIMPLE) 
described  by  Clements,  McGregor,  and  Cohen  (2005),  is  a  general 
purpose  business  model  that  supports  estimating  the  costs  and 
benefits  of  adopting  a  product  line.  There  are  four  basic  cost 
functions  provided  in  SIMPLE:  (1)  How  much  it  costs  to  adopt  the 
Product  Line  approach;  (2)  How  much  it  costs  to  develop  a  core  asset 
base  for  a  particular  scope;  (3)  How  much  it  costs  to  develop  the 
unique  parts  of  a  product  that  are  not  based  on  assets  in  the  core 
asset  base;  and  (4)  How  much  it  costs  to  build  a  product  reusing  the 
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core  assets.  The  model  can  support  a  variety  of  scenarios  by 
manipulating  the  four  basic  cost  functions  and  developing  benefit 
functions  suitable  to  the  particular  application.  The  critical  element  in 
the  economic  model  is  providing  the  relevant  parameters  and  data  for 
the  functions  to  accurately  represent  the  costs  and  benefits.  The 
SIMPLE  Model  is  designed  to  be  easily  usable  as  a  structured  and 
intuitive  tool  and  should  be  considered  a  starting  point.  Other 
economic  modeling  approaches  are  available  for  Product  Line 
analysis.  Model  selection  should  be  based  on  the  resources  available 
and  the  level  of  detail  considered  essential  by  the  organization. 

e.  Establish  funding  resource  level  for  project.  Funding  is  essential 
to  establish  the  Product  Line.  Completion  of  the  business  case 
analysis  and  economic  model  should  provide  solid  footing  for 
establishing  the  funding  levels  and  profiles  required.  Identifying 
sources  of  funding  in  the  DoD  environment  offers  a  unique  challenge. 
A  commercial  entity  would  allocate  funding  based  on  projected  sales, 
Product  Line  breadth  and  depth,  and  perceived  market  advantage.  In 
this  case,  the  private  sector  enterprise  is  trying  to  corner  market 
share,  and  the  investment  is  limited  by  the  expected  outcome.  In  the 
DoD,  market  share  is  meaningless,  but  increased  buying  power  is 
extremely  relevant  to  managers  and  enterprise  executives.  By 
determining  the  cost  to  start  the  Product  Line  versus  the  cost  savings 
projected  across  the  Product  Line,  a  solid  case  for  start-up  budget  can 
be  established. 

2.  Map  project  to  initial  pilot  project  execution  plan.  With  resources,  the 
business  case,  and  technology  assessment  in  hand,  and  the  Product  Line 
scope  defined,  the  next  steps  involve  creating  the  organizational  and 
guidance  documentation  and  processes. 

a.  Product  line  adoption  plan.  The  adoption  plan  is  the  roadmap  to 
take  the  organization  from  its  current  state  through  implementation  of 
the  Product  Line.  The  plan  may  be  as  simple  as  a  plan  of  action  with 
milestones  (POAM),  or  as  elaborate  as  a  multi-year  transformation 
roadmap  with  extensive  state  models,  action  descriptions,  reporting 
requirements,  and  assessment  tools.  The  adoption  plan  should  cover 
the  full  range  of  actions  that  are  needed  to  implement  the  Product 
Line,  call  out  the  products  that  will  be  created  at  each  step,  and 
assign  responsibility  for  accomplishing  the  work  and  delivering  each 
product. 

b.  Organization  chart  and  assigned  personnel  w/duties.  Adopting  a 
Product  Line  approach  includes  adopting  an  organization  structure 
suitable  to  operating  the  Product  Line  factory  once  it  is  established. 
The  Product  Line  team  includes  business  and  technology  managers 
and  workers.  Market  analysts  and  marketers,  software  and 
requirements  engineers,  architects  and  test  engineers,  as  well  as 
business  analysts,  financial  and  business  managers,  configuration 
managers,  and  customer  support  personnel  are  all  needed  at  some 
point  to  establish  and  operate  the  Product  Line  (Northrop,  2004).  It  is 
very  important  that  managers  recognize  the  difficulty  in  changing  an 


ACQUISITION  RESEARCH:  CREATING  SYNERGY  FOR  INFORMED  CHANGE  - 18  - 


organization  within  the  DoD  and  ensure  that  the  assigned  team  is 
both  capable  and  supported. 

c.  Develop  risk  management  process.  A  formal  structured  approach 
to  risk  management  is  an  essential  tool  for  any  complex  undertaking. 
There  are  numerous  models  to  choose  from  with  the  critical  attributes 
being  that  the  Product  Line  Manager  is  comfortable  with  the  tool 
selected,  and  the  tool  is  both  usable  and  informative. 

Phase  II:  Establish  Core  Assets 

Phase  II  starts  the  execution  of  the  Product  Line  adoption  plan.  The  business  case 
analysis,  economic  model,  technology  assessment,  market  assessment,  and  funding  plan 
all  remain  living  documents  that  need  to  be  updated  as  the  project  evolves.  The  adoption 
plan,  organization  and  manning  document  and  risk  management  process  become  the 
operations  template  for  day  to  day  activities. 

Once  the  decision  has  been  made  on  what  to  build,  work  can  begin  on  creating  the 
core  asset  base.  This  section  is  written  from  the  perspective  of  a  reactive  approach,  where 
you  start  with  an  existing  product  as  the  first  member  of  the  Product  Line  and  use  that  seed 
product  to  populate  the  initial  core  asset  base.  To  operate  as  a  factory,  the  Product  Line 
needs  established  processes  and  procedures  to  use  repetitively  to  create  consistent  results 
(Northrop  &  Clements,  et  al.,  2007,  Product  Line  Essential  Activities  section).  Many  of  those 
procedures  deal  with  creating  the  core  asset  base.  Some  deal  with  creating  products  from 
the  core  asset  base,  and  the  rest  describe  supporting  the  product  in  the  field  and  growing 
the  user  community.  Through  the  balance  of  this  section,  the  processes  that  are  part  and 
parcel  to  the  work  and  products  at  hand  are  critical  parts  of  what  must  be  created  to 
establish  the  Product  Line. 

1 .  Decompose  assets  from  seed  product. 

a.  Define  requirements,  engineering  process,  and  document  initial 
product  requirements.  There  are  many  advantages  and  some 
challenges  if  you  use  an  existing  product  as  the  starting  point  for  a 
Product  Line.  Among  the  advantages  of  using  existing  assets 
includes  having  a  working  product  that  has  been  tested  and  possibly 
certified.  Challenges  include  adapting  existing  processes, 
procedures,  and  organizational  structures  to  a  Product  Line  model. 
Also,  the  requirements  engineering  process  for  a  Product  Line  differs 
from  that  of  a  standalone  product  in  important  ways.  Requirements 
engineering  includes  the  processes  of  elicitation  (the  process  of  listing 
and  defining  the  requirements  set),  analysis,  specification,  verification, 
and  management.  These  processes  are  used  to  define,  refine, 
document,  ensure  correctness  and  completeness,  and  schedule  and 
coordinate  activities  to  formally  state  product  requirements.  When  a 
Product  Line  is  involved,  elicitation  must  capture  all  the  anticipated 
variation  points  across  the  lifetime  of  the  Product  Line  (Northrop  & 
Clements,  et  al.,  2007,  Requirements  Engineering  section),  leading  to 
a  potentially  larger  community  of  stakeholders  than  for  a  single 
product.  Since  elicitation  focuses  on  scope,  there  will  be  both  a 
Product  Line  scope  and  a  product  scope  that  must  be  agreed  upon.  It 
is  expected  that  the  requirements  engineering  process  will  result  in 
changes  in  the  scope  description.  The  requirements  documentation 
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should  be  used  for  the  existing  product  as  the  starting  point  for  the 
Product  Line  requirements  engineering  process.  Requirements 
analysis  for  a  Product  Line  is  focused  on  finding  the  commonalities 
and  identifying  the  variations.  These  are  the  same  commonalities  and 
variations  that  should  be  found  in  the  scope  document.  Again  the 
requirements  analysis  will  drive  further  clarification  and  definition  into 
the  Product  Line  scope.  When  the  requirements  specification  is 
written,  it  will  include  both  the  Product  Line-wide  set  of  requirements 
and  product-specific  requirements.  Both  elements  will  require 
verification  by  the  projected  user  communities.  The  requirements 
engineering  process  should  be  applied  to  both  the  core  asset 
development  and  to  product  development. 

b.  Capture  architecture,  define  development  and  evaluation 
processes.  Start  with  the  existing  architecture  from  the  existing 
product,  and  incorporate  the  changes  and  restructuring  required  to 
support  a  Product  Line.  Important  differences  revolve  around  the 
ability  to  establish  and  implement  variation  points  in  the  products 
within  the  structure  of  the  selected  base  architecture.  Once 
established,  the  architecture  must  be  fully  documented  and  evaluated. 
Formalized  and  repeatable  techniques  and  procedures  have  been 
developed  by  SEI  (Northrop  &  Clements,  et  al.,  2007,  Architecture 
Evaluation  section)  and  others  that  can  be  used  with  Product  Line 
architectures. 

2.  Capture  and  document  test  assets.  The  existing  product  was  produced 
and  tested  in  a  formal  manner.  The  artifacts  from  that  process  form  the 
starting  point  for  the  Product  Line  test  assets.  Test  artifacts  include  the 
following: 

■  test  documents,  including  strategy,  test  plans,  and  test  reports; 

■  test  cases; 

■  test  data  sets; 

■  test  software,  including  harnesses  or  scripts;  and 

■  associated  processes. 

For  a  Product  Line,  the  test  program  must  consider  the  variation  points  that 
occur  throughout  the  development  process  and  start  testing  the  software 
artifacts  as  early  as  possible  (Northrop  &  Clements,  et  al.,  2007,  Testing 
section). 

Because  Product  Lines  reuse  core  assets  with  variations  to  produce 
products,  the  number  of  possible  combinations  of  unique  sets  of  assets  can 
become  very  large  as  the  number  of  products  expands.  The  test  program 
must  be  designed  to  start  testing  software  artifacts  as  close  to  the  variation 
points  as  possible  to  minimize  the  test  permutations. 

3.  Develop  and  document  the  process  for  developing  or  acquiring  new 
components.  The  core  asset  base  (Northrop  &  Clements,  et  al.,  2007,  Core 
Asset  Development  section)  includes  the  full  suite  of  things  used  to  create  a 
product  in  a  Product  Line.  Examples  include  architecture  descriptions, 
requirements  documents,  code  components,  processes  for  developing  or 
evaluating  software,  and  tools.  New  assets  are  either  developed  or  acquired 
to  support  new  product  requirements.  Some  are  off-the-shelf  (commercial  or 
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government),  some  are  developed  (in-house  or  commissioned),  and  some 
are  created  by  implementing  new  variation  points  in  existing  assets. 

Changes  to  the  Product  Line  requirements  and  architectures  supporting  new 
behaviors  or  aspects  will  specify  the  components  to  satisfy  the  needs  and 
how  those  components  will  integrate  into  the  product.  The  process  of 
acquiring  new  components  should  include  a  specific  development  process  to 
incorporate  the  variation  mechanisms  specified  in  the  architecture  for  the 
Product  Line(Northrop  &  Clements,  et  al.,  2007,  Component  Development 
section).  New  components  may  also  be  mined  from  existing  assets  in 
repositories  like  the  Navy  SHARE  and  NESI  repositories,  or  from  open 
source  software.  In  each  case,  as  a  component  is  brought  into  the  asset 
base,  it  must  also  include  the  full  interface  definition,  any  needed  code  to 
integrate  the  component  into  the  architecture,  and  an  appropriate  variation 
mechanism.  The  interface  definitions  must  be  clearly  documented,  based  on 
published  open  standards,  and  include  all  information  required  to  support 
integration  by  a  third  party. 

4.  Develop  and  document  the  Product  Line  configuration  management 
process.  Starting  with  the  configuration  management  plan  for  the  existing 
product  and  its  artifacts,  develop  an  expanded  plan  for  the  Product  Line. 
Within  a  Product  Line,  the  core  asset  base  and  the  family  of  products  must  all 
be  managed  together  (Northrop  &  Clements,  et  al.,  2007,  Configuration 
Management  section).  Each  of  the  assets  requires  configuration 
management  so  that  all  their  component  parts,  interface  descriptions, 
variation  points,  and  other  documentation  are  versioned  and  controlled. 
Similarly,  the  products  are  versioned  and  controlled.  Since  the  assets  are 
used  on  more  than  one  product,  changes  to  one  asset  needed  by  one 
product  must  be  managed  in  common  with  all  the  other  products  that  use  the 
same  asset.  The  configuration  management  tools  must  be  complete  and 
provide  very  sophisticated  tracking  of  products  and  assets  and  their 
interrelationships. 
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Figure  5 

Phase  III:  Develop  Product  Line  Production  Processes 

The  Product  Line  should  be  designed  for  ease  of  assembly  and  integration  from  the 
earliest  architecture  definition  through  development  of  the  production  plan.  Using  the  initial 
existing  product  as  a  basis,  the  assembly  and  integration  plans  should  inform  the 
architecture  development,  core  asset  development,  and  the  testing  plan.  This  precept  is  a 
critical  component  of  the  Product  Line  production  process. 

1 .  Develop  and  document  the  prescribed  way  assets  will  be  assembled 
into  a  product.  The  integration  plan  from  the  existing  product  may  be 
suitable  to  use  as  a  starting  point  and  should  be  assessed.  Product 
integration  within  a  Product  Line  involves  combining  core  assets  from  the 
core  asset  base  and  possibly  adding  unique  assets.  The  variation 
mechanism  employed  within  the  architecture  is  used  during  integration  to 
achieve  the  behaviors  and  aspects  that  discriminate  the  current  product  from 
other  members  of  the  Product  Line.  How  that  variation  mechanism  is  to  be 
used  in  assembling  the  product,  and  how  the  components  are  to  be 
integrated,  is  dictated  by  the  architecture  and  documented  in  the  production 
process. 

The  production  tool  set  is  driven  by  the  architecture  and  the  variation 
mechanism.  Among  the  tools  that  may  be  leveraged  for  production,  are 
interface  languages  like  the  Interface  Definition  Language  (IDL)  and  Object 
Constraint  Language  (OCL)  (Northrop  &  Clements,  et  al.,  2007,  Software 
System  Integration  section)  that  allow  one  to  check  the  interfaces 
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automatically  for  consistency  and  completeness;  the  use  of  wrappers  to 
incorporate  components  found  through  mining  whose  interfaces  are  not 
controlled  within  the  Product  Line;  middleware  that  isolates  the  applications 
from  the  data  generators  and  the  user  interfaces;  and  system  generators  that 
are  actually  computer  programs  written  to  select  components  and  set  their 
variability  based  on  parameters  provided  to  the  generator  at  run  time. 
Transitioning  from  a  standalone  product  to  a  Product  Line  may  force  changes 
in  the  production  tool  set  to  accommodate  implementing  and  managing 
variability. 

2.  Develop  and  document  product  line  support  process.  Once  a  production 
plan  is  established,  programs  need  to  update  the  business  case  and 
economic  model.  The  cost  of  operating  the  factory  will  be  driven  by  the 
products  being  built  and  the  staff  needed  to  maintain  the  assets  and  build, 
test,  and  deliver  the  products.  The  organization  chart  and  manning  plan 
should  be  updated  as  required  to  incorporate  production  and  revise  the 
economic  model  to  reflect  the  current  understanding  of  projected  costs. 

An  integral  part  of  getting  a  Product  Line  established  is  the  customer  base  (Northrop 
&  Clements,  et  al.,  2007,  Customer  Interface  Management  section).  Products  in  the  field 
must  be  supported  and  new  products  fielded  to  achieve  the  most  benefit  from  the  Product 
Line  approach.  In  the  initial  market  survey,  sets  of  potential  customers  will  be  identified  who 
are  able  and  willing,  but  reluctant.  Some  of  the  Product  Line  support  team’s  responsibilities 
include  keeping  current  customers  satisfied  and  growing  the  Product  Line  by  finding  new 
customers  for  existing  or  new  products. 

All  of  these  activities  require  funding.  The  Product  Line  Manager  must  create  a 
funding  profile  based  on  the  organization,  tasking  for  creating  new  assets  and  products,  and 
tasking  for  maintaining  and  supporting  existing  products.  The  Product  Line  documentation 
should  provide  a  solid  basis  for  estimating  funding  requirements  and  determining  funding 
requirements. 
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Figure  6 

Phase  IV:  Develop,  Document  and  Deliver  New  Product  Variations 

When  the  initial  set  of  Product  Line  processes,  assets,  and  plans  are  complete  and 
the  organization  has  been  established  and  manning  is  in  place,  it  is  time  to  use  the  factory 
to  create  the  second  product  in  the  Product  Line.  A  legacy  of  the  first  product  is  that  many 
of  the  analyses  and  initial  process  documents  will  have  been  created  as  “lite”  versions, 
designed  to  document  what  is  known  at  the  time.  These  materials  will  serve  as  place 
holders  for  later  elaboration  as  processes  are  tested  and  knowledge  is  gained.  The  testing, 
elaboration,  and  revisions  to  the  Product  Line  documentation  and  operations  are  critical 
objectives  during  development  of  the  second  product  in  the  line. 

1 .  Develop  new  product  requirements.  The  first  step  is  to  use  the  Product 
Line  requirements  development  process  and  the  existing  Product  Line 
requirements  document  to  develop  and  document  the  requirements  for  the 
second  product.  At  the  same  time,  the  additional  product  is  added  to  the 
economic  model,  and  the  new  product  behaviors  and  aspects  are  reviewed 
against  the  Product  Line  scope  to  ensure  they  fall  within  the  set  of  “in” 
characteristics.  In  the  event  the  scope  is  revised,  a  review  of  the  technology 
assessment  and  the  business  case  should  be  undertaken  to  ensure  the 
changes  do  not  invalidate  prior  work. 

2.  Review  new  product  against  the  Product  Line  architecture.  The  Product 
Line  architecture  must  support  the  full  set  of  product  requirements.  If  the  new 
product  requires  behaviors  or  features  that  cannot  be  supported  by  the 
architecture,  either  the  architecture  must  be  revised  or  the  product  will  not  fall 
within  the  scope  of  the  Product  Line.  The  new  product  may  require  an 
addition  to  the  architecture  to  incorporate  an  additional  variation  mechanism 
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or  a  method  to  incorporate  outside  assets  that  were  not  originally 
contemplated  by  the  architect.  In  any  event,  the  requirements  and  the 
architecture  must  work  together  before  moving  forward.  Any  changes  to  the 
architecture  must  be  fully  documented  and  reviewed.  An  assessment  report 
on  the  process  must  be  created  to  capture  the  results  and  evaluate  the 
effectiveness  and  validity  of  the  architecture  development  and  process  when 
complete. 

3.  Update  core  asset  base  and  unique  assets  to  support  the  new  product. 

New  core  assets,  variation  points  in  existing  core  assets,  or  unique  or  outside 
assets  (Northrop  &  Clements,  et  al.,  2007,  Mining  Existing  Assets  section) 
may  be  needed  for  the  new  product.  Using  the  component  development 
process  already  devised,  update  the  assets  to  meet  product  needs.  Evaluate 
these  processes  and  procedures,  update  them  as  needed,  and  generate  a 
report  documenting  the  results. 

4.  Assemble  and  integrate  product  assets.  Use  the  assembly  and  integration 
plan  to  create  the  new  product.  Production  should  use  the  production  tools 
previously  selected  to  demonstrate  their  suitability  and  sufficiency  for 
completing  the  task.  The  results  of  this  work  will  be  a  product  ready  for  final 
testing  along  with  a  report  on  the  efficacy  of  the  process  and  the  tools. 

5.  Execute  product  test  strategy.  The  test  strategy  includes  testing  at  every 
level  of  development  and  integration.  While  the  testing  for  the  original 
product  may  all  have  been  conducted  after  coding  and  integration,  the 
strategy  should  have  been  revised.  For  the  Product  Line,  it  is  essential  to 
test  components  as  they  are  developed  for  the  core  asset  base,  incorporated 
from  outside  sources,  or  modified  to  incorporate  new  variation  points  and 
behaviors.  For  a  new  product,  the  test  documents,  test  cases,  test  software, 
and  test  data  may  all  require  updates  to  reflect  changes  in  the  assets  and 
changes  in  the  requirements  of  the  final  product.  The  test  program  will  start 
well  before  assembly  and  integration.  Following  test  completion,  a  test 
process  assessment  report  is  needed  to  inform  updates  and  adjustments  to 
the  test  strategy  for  future  products. 

6.  Evolve  and  update  Product  Line  growth  and  support  team.  At  initial 
product  release,  critical  support  functions  must  be  in  place.  Configuration 
management  (CM)  and  customer  care  are  two  of  the  most  important. 
Configuration  management  for  a  Product  Line  was  originally  implemented  in 
developing  the  processes  and  procedures  for  standing  up  the  Product  Line. 
Customers  now  become  stakeholders  and  participants  in  the  CM  process. 
Product  Line  growth  is  fueled  by  finding  new  customers  for  existing  products 
from  among  the  able  but  reluctant  potential  customers,  or  by  working  with 
potential  customers  to  develop  new  products  within  the  line.  The  support 
team  in  a  commercial  environment  would  include  a  marketing  group  for  this 
activity.  The  product  growth  group  serves  the  same  function  in  the  DoD 
environment. 

Customer  care  includes  supporting  initial  integration  of  the  Product  Line 
products  into  the  customers  systems  or  platforms;  establishing  a  defect 
reporting,  correction,  and  feedback  system;  and  working  with  customers  on 
their  needs  for  product  improvements  or  adding  additional  product  features. 
This  part  of  the  support  organization  is  essential  to  maintaining  and  growing  a 
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Product  Lines  footprint.  Everyone  grudgingly  accepts  that  software  products 
will  have  defects,  but  no  one  happily  tolerates  non-responsive  customer 
support  or  continues  to  buy  products  that  cannot  or  will  not  address  and 
correct  the  defects. 

The  support  team  is  also  responsible  for  the  development  of  a  cost/price 
model  (an  adjunct  to  the  economic  model)  to  incorporate  the  support  costs 
into  the  development  costs  for  products  from  the  Product  Line.  Since  the 
support  team  is  shared  across  the  Product  Line,  the  incremental  cost  of 
supporting  a  new  product  should  be  less  than  that  experienced  by  standalone 
products.  Other  aspects  of  the  support  costs  include  addressing  software 
reliability  and  problem  resolution.  Based  on  past  experience,  the  reuse  of 
assets  is  expected  to  improve  their  reliability.  Problem  resolution  times  will 
depend  on  the  effectiveness  of  the  factory  processes  and  the  configuration 
management  process.  All  of  these  costs  should  be  collected  and  used  to 
refine  and  update  the  cost/price  model  and  improve  its  ability  to  project 
conditions  as  more  and  new  products  are  added. 

7.  Define  a  product  release  and  distribution  strategy.  During  the  initial 

technology  assessment,  care  was  taken  to  determine  the  best  apparent  set  of 
practices,  tools,  and  technologies  to  incorporate  in  the  Product  Line.  If  the 
Product  Line  is  successfully  established,  there  is  a  danger  of  becoming 
wedded  to  the  successful  past  as  time  passes  and  technology  moves  ahead 
(Northrop  &  Clements,  et  al.,  2007,  Technology  Forecasting  section).  It  is 
critical  to  transform  the  technology  assessment  into  a  technology  roadmap 
that  provides  for  continuing  assessment,  evaluation,  and  migration  as  tools, 
techniques,  and  processing  evolve.  Sometimes  the  technology  change  will 
enable  new  behaviors  and  allow  products  to  meet  new  or  different 
performance  requirements,  while  other  advancements  may  enable  reduction 
in  the  cost  or  time  to  field  new  products  within  the  line.  Each  technology 
improvement  offers  an  opportunity  to  grow  the  Product  Line  by  meeting  the 
performance,  cost,  and  schedule  requirements  of  new  customers. 

Another  plan  needed  for  the  support  team  is  the  Product  Line  Growth  plan.  The 
growth  plan  incorporates  deliberate  strategies  to  find,  inform,  learn  from,  and  collaborate 
with  customers  for  current  and  new  products.  The  growth  plan  is  informed  by  the 
technology  roadmap  as  well  as  the  cost/price  model  and  the  Product  Line  scope.  Potential 
approaches  to  Product  Line  growth  within  the  DoD  include  use  of  federated  repositories  for 
Product  Line  and  product  descriptions,  forming  communities  of  interest  in  the  Product  Line 
domain,  and  enterprise  wide  workshops  and  symposia  on  Product  Lines  and  better  buying 
power. 

Enabling  Product  Line  Success 

Product  Lines  require  technical  and  business  constructs  which  are  also  found  in 
Open  Architecture  systems.  Technical  examples  include  reliance  on  core  components, 
adherence  to  published  interfaces,  and  use  of  common  services  to  keep  the  implementation 
both  loosely  coupled  and  modular.  The  introduction  of  an  open  business  model  (OBM)  is 
also  important  for  Product  Line  success.  An  OBM  is  an  approach  for  doing  business  in  a 
transparent  way  that  leverages  collaborative  innovations  of  numerous  participants  across  an 
enterprise,  permitting  shared  risk,  maximized  asset  reuse,  and  reduced  total  ownership 
costs.  Noted  management  scholar  Henry  Chesbrough  (2006)  has  distinguished  an  open 
business  model  from  a  traditional  business  model  as  follows: 
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A  business  model  serves  two  important  functions:  1 .  It  creates  value;  and  2.  It 
captures  a  portion  of  that  value.  It  creates  value  by  defining  a  series  of  activities 
from  raw  materials  to  final  customer  that  will  yield  a  new  product  or  service  with 
value  being  added  throughout  the  various  activities.  The  business  model 
captures  value  by  establishing  a  unique  resource,  asset,  or  position  within  that 
series  of  activities,  where  the  firm  enjoys  a  competitive  advantage. 


Alternatively,  he  describes  an  open  business  model  as  follows: 


An  open  business  model  uses  this  new  division  between  innovation  and  labor — 
both  in  the  creation  of  value  and  in  a  capture  of  a  portion  of  that  value.  Open 
models  create  value  by  leveraging  many  more  ideas,  due  to  their  inclusion 
of  a  variety  of  external  concepts.  Open  models  can  also  enable  greater  value 
capture,  by  using  a  key  asset  not  only  in  the  company’s  business,  but  also  in 
other  companies  businesses  (Chesbrough,  2006). 


Incentivizing  Product  Lines 

Programs  that  receive  ample  funding  to  conduct  their  own  unique  development  of 
systems,  sub-systems  and  components  have  little  incentive  to  seek  opportunities  for  reuse 
and  participate  in  Product  Lines.  A  2006  survey  conducted  by  the  Navy’s  Open  Architecture 
Enterprise  Team  (OAET)  found  that  74%  of  those  interviewed  indicated  there  were  no 
incentives  for  employees  to  identify  opportunities  for  reuse,  50%  said  there  were  no 
incentives  for  programs  to  reuse,  and  68%  said  there  were  no  incentives  for  programs  to 
develop  reusable  assets  (OEAT  Survey,  2006). 

The  current  structure  for  developing  systems  includes  rules  and  processes  which  are 
often  contrary  to  achieving  Enterprise  value  and  cost  efficiency.  It  follows  that  in  order  to 
achieve  change,  careful  crafting  of  incentives  is  important  to  gain  desired  results. 

Provide  Incentives  for  Creating  and  Using  Product  Lines 

Reducing  the  program  budget  to  a  level  that  does  not  support  building  the  available 
component  from  scratch  can  put  enough  pressure  on  the  program  to  dictate  use  of  the 
Product  Line  component.  Half  of  the  resulting  savings  could  be  held  in  reserve  and,  after 
component  integration,  released  back  to  the  Program  Manager  for  feature  additions  or 
upgrades  on  any  Product  Line  item  the  Program  Manager  believes  appropriate. 

Remove  Incentives  for  Bad  Behavior  in  Acquisition 

Sole-source  award  programs  where  lack  of  competition  drives  prices  higher  and 
encourages  vendor  lock  have  become  the  norm  for  the  Naval  Enterprise.  OA  and  Product 
Lines  must  become  mainstream  practices  within  the  Enterprise  to  remove  incentives  for  bad 
behavior  in  acquisition. 

Expectations  should  be  established  that  when  a  program  expects  to  award  contracts 
above  a  fixed  level  (for  example,  programs  over  $10  million  for  R&D  alone),  that  the 
program  can  benefit  from  Open  Architecture  and  Product  Lines.  The  Naval  Enterprise  must 
require  these  programs  to  move  to  OA  and  Product  Lines. 
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Sponsor  Holds  Contests  for  High-Performance  Acquisition  Behavior  and 

Product  Lines 

How  can  the  Enterprise  know  how  good  it  can  be  without  a  challenge?  Rewarding 
excellent  or  appropriate  acquisition  behavior  with  benefits  that  help  the  program  can  only 
cause  more  good  behavior. 

Support  and  Collaborate  with  Program  Managers 

Program  Managers  are  being  asked  to  take  on  a  new  business  model.  This  will 
require  learning  and  effort.  They  must  own  and  adopt  the  new  model  so  that  Open 
Architecture  and  Product  Lines  can  be  successful.  The  Enterprise  must  resist  the  tendency 
to  overburden  Program  Managers  with  rules  and  process,  on  the  premise  that  PMs  can  be 
prevented  from  failing.  We  should,  on  the  other  hand,  provide  sufficient  tools  to  give  them  a 
place  to  start  with  Product  Lines  and  interactive  support  to  provide  collaboration  in  the 
adoption  and  development  of  the  new  business  model.  We  must  open  up  the  armory,  issue 
our  most  precise  acquisition  weapons,  and  pilot  our  way  to  success  by  allowing  failures  and 
successes  to  give  professionals  experience  in  the  competitive  marketplace.  We  should  pare 
back  management  oversight  to  essential  measurements,  and  stress  planning  and  iteration, 
rather  than  rigid  adherence  to  process  and  rules.  Programs  are  completed  by  hard  working 
people  making  good  decisions. 

Shift  Responsibility  to  Resource  Sponsors 

Functional  requirements  and  money  flow  down  from  the  Resource  Sponsors.  These 
important  individuals  are  customers  that  must  engage  the  Program  Managers,  encouraging 
them  to  invest  in  Product  Lines.  Product  Lines  can  be  a  solid  investment  for  the  Resource 
Manager,  since  owning  a  reusable  and  transportable  feature  that  can  be  integrated  and 
deployed  quickly  on  new  and/or  existing  platforms  saves  money,  time,  and  improves 
operational  availability  by  reducing  resource  requirements  for  longer  test  cycles. 

Restrain  Resources  to  All  Programs 

According  to  a  study  performed  by  Lt.  Col.  Dan  Ward  (2009),  USAF,  programs  over 
$10  million  in  value  have  a  0%  chance  of  successfully  delivering  a  working  product  that 
meets  its  performance  requirements  on  schedule.  By  allowing  deadline  slip  and  delaying 
delivery,  the  probability  of  project  success  worsens.  Comparatively,  smaller,  less  complex 
programs  that  leverage  Product  Lines  are  more  likely  to  be  delivered  on  time  and  on  budget, 
with  a  direct  correlation  between  smaller  budget  and  shorter  execution  times  for  program 
success.  Reducing  and  restraining  a  program  from  the  inception  can  result  in  savings  that 
result  from  dramatic  restructuring  and  rethinking  of  the  acquisition  program. 
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Figure  7 

Create  a  Marketplace  for  Competition  and  Small  Business 

As  acquisition  professionals,  we  are  responsible  for  the  outcomes  of  our 
development  programs.  The  path  to  successful  OA  Product  Line  programs  begins  with  the 
Request  for  Information  (RFI),  when  the  outline  of  rules  and  how  the  program  will  be 
competed  is  defined  to  the  marketplace.  The  target  system  should  be  decomposed  into  unit 
sizes  that  are  functionally  decoupled  from  the  platform,  yet  cohesive  in  nature.  A  useful 
example  is  the  SONAR  systems  installed  on  ships  or  submarines.  Although  the  platform  is 
different,  much  of  the  implementation  can  be  shared  between  the  two.  Defining  roles  for 
competition,  such  as  having  a  designated  Prime  Integrator  and  designated  Application 
Subsystems  Developers  (primarily  drawn  from  small  businesses)  can  reduce  the  conflicts 
between  large  and  small  business.  In  this  case,  we  could  limit  the  Prime  contractor  to  only 
performing  integration,  because  of  the  conflict  of  interest  that  may  arise  if  that  provider  were 
allowed  to  develop  and  select  applications.  By  their  position,  Primes  would  have  an 
advantage  over  the  subsystem  developers. 

Within  the  Product  Line  construct,  the  core  asset  base  provides  a  natural  place  to 
compete  components.  The  ability  to  use  assets  created  within  or  outside  of  the  Product 
Line  factory  organization,  including  COTS  and  mined  assets,  allows  the  Product  Line 
manager  to  establish  and  maintain  an  open  competitive  environment  based  on  value  and  a 
natural  entry  point  for  small  business. 

Provide  Web-Enabled  Tools  to  Encourage  Transparency 

In  many  cases,  programs  lack  the  internal  communications  capabilities  they  need  to 
effectively  work  across  traditional  stovepiped  programmatic/domain/Service  boundaries.  For 
each  program,  a  common,  easy  to  use  web-based  collaboration  portal  where  project 
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information  is  securely  held,  and  made  available  to  the  community  as  appropriate,  is 
required.  This  environment  would  provide  a  green  field  for  web  enabled  program 
management,  including  capturing  products  associated  with  ongoing  development  and 
deliveries,  and  providing  transparency  to  all  stakeholders.  Some  larger  programs  have  filled 
the  void  with  collaboration  tools  for  their  internal  use,  demonstrating  the  viability  of  this 
mechanism.  The  Naval  Enterprise  may  in  the  future  provide  a  standard  environment  for  use 
in  any  program  that  needs  such  a  resource. 

Apply  Governance  to  Protect  Small  Business 

Small  Business  Innovative  Research  (SBIR)  contracts  are  used  by  highly  innovative 
and  competitive  small  businesses  to  cleave  a  foothold  into  the  defense  marketplace. 

Without  governance,  large  firms  have  shown  a  repeated  pattern  of  cutting  small  businesses 
out  of  the  marketplace.  When  this  occurs,  the  government  loses  a  competent  innovator  and 
price  competitor — increasing  the  potential  for  mediocre  performance,  cost  overruns,  and 
schedule  delays. 

Conclusion 

The  Naval  Enterprise  is  at  a  sea  change  with  respect  to  its  acquisition  behavior. 

More  highly  advanced  systems  must  be  acquired  with  fewer  resources.  During  a  panel 
discussion  at  the  January  201 1  Surface  Navy  Association  Symposium,  RADM  Dave  Lewis, 
USN,  PEO  SHIPS,  discussed  cost  growth  in  ship  acquisition  over  recent  years.  Projecting 
that  growth  into  the  future,  he  posited  that  either  the  Navy  would  not  be  able  to  afford  ships, 
or  the  Navy/Industry  team  must  innovate  and  find  ways  to  acquire  our  ships  at  lower  prices 
while  maintaining  a  profitable  industry.  With  a  large  fraction  of  the  cost  of  a  surface 
combatant  dedicated  to  the  combat  system,  and  a  significant  portion  of  the  ship’s  systems 
cost  dedicated  to  software,  Product  Lines  and  Open  Architecture  offer  a  real  opportunity  to 
innovate  and  save  precious  taxpayer  resources.  Open  Architecture  is  a  proven  method 
within  the  Naval  Enterprise  to  reduce  total  ownership  cost.  Product  Lines  have  enjoyed 
popularity  within  leading  corporations  for  years,  and  are  a  good  fit  for  encouraging  savings 
within  the  Naval  Enterprise.  Together,  Open  Architecture  and  Product  Lines  provide  the 
best  opportunity  to  save  money  and  improve  performance  in  Naval  Enterprise  Acquisition. 
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Important  Concepts 


□  Competition  and  Innovation 


□  Rapidly  Fielding  and  Upgrading  Systems 


□  Software  and  Hardware  Design  Reuse 


■  A  set  of  components  or  products  created  from  shared  core  assets 
delivering  features  and  capabilities  that  address  the  specific  needs 
of  a  specific  market  segment  or  mission  capability. 

□  Smart  Phones 

□  Smart  Phone  Software 

□  Automobiles 

□  Personal  Computers 

□  Marine  Radars 

□  Marine  Navigation  Systems 

■  Core  Assets  include  drawings,  architecture,  patterns,  code  modules, 
test  suites  and  tools,  and  any  other  cumulative  product  from  the 
engineering  effort 


Product  Lines  (introduction) 


I 


3 


https  ://acc.dau  .mi  l/oa 


Open  Architecture  (introduction) 


■  Modular  designs  with  loose  coupling  and  high  cohesion 

■  Continuous  design  disclosure 

■  High  Reuse  of  designs  of  components  and  systems  to  minimize  cost 

■  Enhanced  transparency 

■  Competition  and  collaboration  leading  to  development  of  alternative 
solutions  and  sources 

■  Investment  based  on  analysis  of  which  components  will  change 
most  often  based  on  technology 


Competition  through  open  access  to  qualified  third  party  providers 
for  components 


Open  Architecture  Product  Lines  (introduction) 

■  Open  Architecture  Core  Assets 

□  Open  managed  reused  components  -  strategic  reuse 

□  Published  architecture  that  specifies  how  features 
and  behaviors  are  varied  between  products 

□  Assets  can  be  competed  as  technology  advances 
and/or  mission  needs  change 

□  Reusable  test  scripts,  plans,  assets  and  harnesses 
shorten  process  and  simplify  execution 


Combining  the  power  of  OA  with  the  leverage  of  Product  Lines 


roduct  Line  Advantages  in  the  DoD  Marketplace 
(Benefits) 


■  Strategic  Reuse 

□  Lowers  Cost 

□  Lowers  Risk 

□  Shortens  Development  Time 

■  Product  Line  Maintenance 

□  Shared  Core  Assets  -  maintained  for  one  is  maintained  for  all 

□  Common  Code  between  products  yields  fewer  software  faults  as 
number  of  products  increases 

□  Built  in  variation  mechanisms  simplify  product  evolution  - 
changes  or  additions  to  requirements  generate  a  new  product 
based  on  core  assets  plus  some  new  or  altered  module(s) 


Product  Line  Advantages  in  the  DoD  Marketplace 


Stand  Alone 


► 


stf  r= 


Relative  Costs,  Standalone  Versus  Product  Line 
(Benefits) 


■  Standalone  ■  Product  Line 


□  Productivity  -  A 

□  Schedule  -  B 

□  Cycle  Time  -  C 

□  Quality  -  D 


□  Productivity  -  3  to  7 
Times  A 

□  Schedule  -  1  /50th  to  Vz 
of  B 

□  Cycle  Time  -  1/3  to 
1/5  of  C 

□  Quality  -  7  to  1 0  times 
better  than  D 


Initial  Product  in  Product  Line;  Costs  may  be  equal  or  higher 
Costs  for  Additional  Products  Decline  as  more  are  Added 


SEI  Case  Studies:  http://www.sei.cmu.edu/productlines/casestudies/ 


Some  Opening  Arguments  (Starting  up  a  Product  Line) 


Data  Rights 

■  Programs  interested  in  Sharing  Risk 

■  Some  shared  Requirements 

■  Organizational  and  Funding  Construct  for  Shared  Production 

■  Government  to  Government  Producer/Customer  governance 
structure 

Need  for  multiple  similar  products  suitable  for  a  product  line 


Starting  or  Transitioning  to  a  Product  Line  (Startup) 


Pilot  Projects 

■  Use  Existing  Products  and  Artifacts  as  Entering  Arguments  for  Core 
Assets,  Processes  and  Tools  -  Re-engineering  to  Adopt  the  Product 
Line  Paradigm 

■  Establishing  a  Framework  for  the  Naval  Enterprise  and  Using  that 
Framework  as  a  Guide  to  Achieve  Consistent  Implementation 
Concepts  and  Approaches 

■  Learning  and  Adapting 


Product  Line  Startup  Phases 


Phase  I  -  Deciding  What  to  Build:  Analysis,  Scoping,  Funding  Plan, 
Product  Line  Adoption  Plan,  Risk  Management,  and  Initial 
Organization  Chart 

■  Phase  II  -  Establishing  Core  Assets:  Requirements,  Architecture, 
Software  Modules,  Test  Assets,  Middleware,  Test  Plan,  and 
Configuration  Management  Plan 

■  Phase  III  -  Develop  the  Product  Line  Production  Processes: 
Assembly  Plan,  Production  Tools,  and  the  Product  Support  Plan 

■  Phase  IV  -  Use  the  Product  Line  Variation  Mechanism  to  Develop, 
Deliver,  and  Support  Additional  Products 


Phase  I:  Deciding  What  to  Build 


Does  your  product  fit  in  a  Product  Line? 

□  Similar  related  products  envisioned? 

□  How  do  they  vary?  What  mechanism  implements  the  variation? 

■  Is  there  a  market  for  the  Product  Line? 

□  How  wide?  How  Deep? 

□  Are  there  willing  and  able  customers? 

■  Is  the  technology  available  to  implement  the  product  and  variation 
mechanism 

□  Suitable  technology? 

□  Sufficient  technology? 

■  Does  the  approach  make  economic  sense? 

□  Economic  Model  and  Business  Case 

□  Are  there  over-riding  intrinsic  value  benefits? 

□  Are  funds  available  for  implementation/transition? 


Phase  II:  Establish  Core  Assets 

■  Requirements  Engineering  Process  and  Initial  Product 
Requirements 

□  Variation  points  across  the  envisioned  Product  Line 

□  Product  wide  and  product  specific  requirements 

■  Architecture  and  Architecture  Analysis 

□  Define  the  variation  mechanism 

□  Capture  the  variation  points 

■  Capture  and  Document  Test  Assets 

□  Test  Documents 

□  Test  Cases 

□  Data  Sets 

□  Harnesses  and  Scripts 


Phase  II:  Core  Assets  (Continued) 


■  Components  -  Supporting  the  Behaviors  and  Aspects  as  Specified 
in  the  Requirements  in  the  Manner  Prescribed  in  the  Architecture 

□  From  existing  product 

□  New  development 

□  Acquire  from  others 

□  All  built  or  configured  to  implement  product  variation  as  specified 
in  the  architecture 

■  Configuration  Management  Process 

□  All  the  assets 

□  All  the  products 

□  Tools  capable  of  managing  the  “many-to-many”  relationships 
between  core  assets  and  products 


Phase  III:  Develop  the  Product  Line  Production  Process 

■  Develop  the  Product  Line  Assembly  Plan 

□  Informed  by  the  architecture  and  components  from  the  core 
assets 

□  Implements  the  variation  mechanism(s)  planned  at  architecture 
development 

□  Based  on  initial  product  artifacts  when  using  a  reactive 
implementation 

■  Develop  and  Document  a  Product  Line  Support  Process 

□  Product  distribution  and  integration  support 

□  Customer  feedback  and  issue  management 

□  Product  defect  correction  management 

□  Product  improvement  planning  and  implementation 


Phase  IV:  Filling  the  Product  Line 


■  Create  the  2nd  Product 

□  Use  the  Product  Line  factory  and  the  variation  mechanism  to 
create  the  2nd  Product 

□  Update  the  plans,  processes  and  analyses  as  lessons  are 
learned 

□  Add  to  the  core  asset  base  as  needed  to  create  the  new 
products 

■  Add  Scope  to  the  Product  Line 

□  Initial  envisioned  products  will  never  be  exactly  what  gets 
produced 

□  Unforeseen  customer  needs  will  require  products  that  extend  the 
scope  of  the  Product  Line  or  change  its  variation  points 


Enabling  Product  Line  Success  (Startup) 


Establish  Open  Business  Models 

■  Use  Incentives 

■  Support  and  Collaborate  with  Program  Managers 

■  Engage  Resource  Sponsors  as  Participants 

■  Implement  Web  Enabled  Tools  for  Transparency 

■  Apply  Governance  to  Protect  Small  Business 


Summary  (Why  Bother) 


■  Current  federal  budget  deficits  are  unsustainable  and  while  all 
sectors  will  be  carefully  scrutinized  and  trimmed,  trimming  defense 
dollars  is  less  personal  than  trimming  Social  Security  and  medical 
benefits  or  slicing  away  education  support  funding  from  people  we 
know. 

■  While  fewer  dollars  are  available  for  defense  systems,  the  cost 
growth  of  those  systems  continues  to  outpace  similar  technical 
advances  in  the  commercial  sector. 

■  Open  Architecture  Product  Lines  aren’t  always  the  solution, 
however,  when  they  are  a  solution  they  present  an  opportunity  to 
reduce  the  cost  of  software  intensive  systems  while  improving 
capability,  quality,  and  reliability  and  giving  industry  an  opportunity 
to  continue  to  be  profitable. 


